NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/13611

Internet Message Format | 1996-08-05 | 3.6 KB

Path: news.sprintlink.net!datalytics!usenet
From: Rob Stewart <[e-mail]>
Newsgroups: comp.lang.c++
Subject: Re: Inheritance problem...and other stuff
Date: Tue, 26 Mar 1996 10:37:43 -0500
Organization: Datalytics, Inc
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: 204.62.224.71
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (WinNT; I)

Wang TianXing wrote:
>
> On 23 Mar 1996 14:49:22 GMT, [e-mail](Pete Grant)
> wrote:
>
> | On Mar 23, 1996 09:01:07 in article <Inheritance problem...and other
> | stuff>, '[e-mail](Mark Feldman)' wrote:
> |
> | >2nd Question:
> | >
> | >What's the standard way of storing such an array to a file and
> | >retrieving it? I could always assign an ID number to each class type
> | >and load them using case statements but this seems messy. I notice that
> | >MFC and OWL seem to use tables to handle the dispatching of windows
> | >messages. Would it be feasable to use this for saving the array info to
> | >a file? Idealy I would like each function to inherit a serialization
> | >function which they can overload to save and restore their data, but
> | >how can I make the loading routine know what type of class to create in
> | >the first place while still keeping the code tight and clean?
> | >
> | There's only one way:  store the type information in the file.  An
> | enum is probably best; alternately, a name string would work also.
> | When you read the data back in, you must check the type info and
> | create an object of appropriate type.
> |
> | There are standard idioms (Coplien's book, for example) for simulating
> | virtual constructors -- I have mixed feelings of those since they
> | are just a thin veil for hiding what you are really doing.  There's
> | really no such thing as a virtual constructor in C++ and I feel a bit
> | uneasy with idioms that try to make it look like they exist.  But
> | at the same time, I can see the benefits also.

Thinly veiled or not, anything that encapsulates what you're
doing is valuable.  For example, the age-old C++ problem of a
class hierarchy having a virtual function that returns a base
class pointer despite the class in which it is used is a pain.
Using an inline mf to encapsulate the inevitable cast to the
derived type is useful.  It eliminates having to write the cast
everywhere.  (In fact, when your compiler supports the new casts
and rtti, your inline function can take advantage of that to
validate its casting.  Of course, when your compiler supports
that, it might support the new ability to return the derived
type pointer while still overriding the virtual function in the
base class!)

As for using an idiom to simulate what is not in the language is
hardly new.  For example, C/C++ don't support linked lists.
Does that mean we shouldn't implement them?  Of course not.  If
your problem is with calling these things "constructors," and
you consider that constructors are specifically defined by the
language, then give them another name.  Once the semantics are
out of the way, you'll have a useful idiom available for your
use when you need it.

>
> In Borland C++, there is a Streamable Class hierarchy, which does what
> Mark wants and even more.  Search TStreamable in the online help.
>

MFC does this with its Serialize function in classes derived
from CObject.  Rogue Wave's Tools.h++ does this with saveGuts
and restoreGuts in RWCollectable.

> ---
> Wang TianXing

--
Robert Stewart        | My opinions are usually my own.
Datalytics, Inc.    | [e-mail]